Sorry about that. @LekoArts fixed it in #31092 just upgrade gatsby-plugin-google-cloud and you'll be fine.

Thanks for quick response Kyle. Will hang on for PR merge to try it out.

This is out now in 3.5. When you have it up and running, share a link, I'd love to see it in action!

Thanks Kyle, it's all working like clockwork now. Thanks for the quick fix.

The site is up at:

https://gatsbyfunctionsfaunamain.gatsbyjs.io/

this is demo blog so, please feel free to play around with it:

• Try going to a blog post and submitting a non-spammy comment. The site will automatically rebuild on Gatsby Cloud. Give it a couple of minutes and refresh, and your comment will be included with all the other site content statically generated on build.
• To test a spam comment, either set the name field to viagara-test-123 or email to akismet-guaranteed-spam@example.com and submit the comment. You will see the same message that your comment will be reviewed, but this time the site will not be rebuilt and even when it is later rebuilt (manually or by a genuine comment), the spam comment will not be included.

One request... could you make the client-ip header available in the handler request headers? Seems not to be exposed currently. This will be used in the Akismet spam detection. Using the client front end to get the user IP for now as a workaround.

Happy to include some Akismet and fauna simplified examples in your gatsby-functions-beta repo. Just let me know.

Rodney

soooo cool! Just tried it out on https://gatsbyfunctionsfaunamain.gatsbyjs.io/best-medium-format-camera-for-starting-out/ 🎉

Fauna + Akismet examples would be fantastic! Just put up a PR.

Yeah, getting the client ip set on the header would be great. I'll relay it to the team.

The team's aware of the issue. I created this roadmap item so you & others interested can follow along. Just pop over and upvote it & you'll get notified when it's shipped https://gatsby.canny.io/gatsby-cloud/p/set-x-forwarded-for-header-for-functions-to-get-the-actual-client-ip

@krismorf @KyleAMathews I gave it a shot here https://github.com/michaellopez/gatsby/tree/feat/function-queries. The commit basically adds the ability to do queries in the functions. E.g.

import { GatsbyFunctionRequest, GatsbyFunctionResponse, graphql } from "gatsby"

export default function handler(
  req: GatsbyFunctionRequest,
  res: GatsbyFunctionResponse
) {
  const data = graphql`
    query {
      site {
        id
        siteMetadata {
          title
        }
      }
    }
  `

  res.send(`Data: ${JSON.stringify(data)}`) //  Data: {"data":{"site":{"id":"Site","siteMetadata":{"title":"Gatsby Default Starter"}}}}
}

This should improve on @krismorf use case of exposing data.

I accomplished this by moving function compilation from onPreBootstrap to onPostBuild for build and onCreateDevServer for develop and adjusting query extraction to support functions.

I'm aware that Gatsby is reluctant to add more API surface so adding a new phase/step felt outside the scope when I started looking into this. So I tried to keep it minimal, but the commit does touch files outside packages/gatsby/src/internal-plugins/functions/, unfortunately. Mainly to add support for query extraction that is not page query or static query. I started out wanting to only do it from inside packages/gatsby/src/internal-plugins/functions/ (and I believe it might be possible, just have to think about and fiddle with it a bit more) but ended up doing it this way just to get something on here to move the discussion forward and showcase the approach in case its an acceptable path forward. Also no tests, so naturally consider it a draft/wip to give us some direction here. Any feedback appreciated.

Huh, super interesting!

This definitely works. The basic idea here is to bind data at build-time to a function. Accessing it through the data layer is an obvious step — I wonder a) how common this need is i.e. common enough to create a special API for it and b) if it'd be better to just make it generic. E.g. a function could export another function like getStaticData that'd be called at build-time e.g.

export async function getStaticData ({ graphql }) {
  const data = await graphql(graphql`
    query {
      site {
        id
        siteMetadata {
          title
        }
      }
    }
  `)

  return data
}

export default function handler (req, res, { data }) {
  res.json(data)
}

BTW on timing — we're approaching the initial GA launch of functions so it's very unlikely we'll make any changes discussed here (other than when we run functions) in the near term.

@KyleAMathews I also contemplated that exact pseudo code you wrote when writing my branch. I discarded it because it felt strange and awkward to alter the handler signature, it feels very "set in stone" as (req, res) almost everywhere. I'm not really knowledgeable as to how functions are deployed in Gatsby Cloud, but I would really like Gatsby Functions to remain compatible with/deployable on other services that offer cloud functions too. Anyway, that's why I opted for my approach.

Also, I'm not so sure that making it generic like that would have any great benefits, as the data fetching from any source but Gatsby graphql server could be done in the handler itself at runtime. Having said that maybe someone else will come up with a great use case/pattern with an approach like getStaticData.

Regarding timing, understood. I can make a PR with only the order functions are compiled in, if you want that?

We're planning to extract a functions runtime as a separate package that will consolidate how we run functions in gatsby develop, gatsby serve and in Cloud (we have to manually keep them in sync right now which isn't great). That could be used to setup Gatsby Functions on other services. So a third "context" parameter would be manageable.

That being said, yeah, there's not a lot of benefit to shipping support for fetching from elsewhere because as you say, you can easily do that at runtime.

Yeah, if you could PR moving function compilation to onPostBootstrap to unlock the write out json and import it into a function approach. Writing out the data in exports.createPages then would work (which doesn't make a lot of sense semantically). I'm on vacation now actually so won't review until next week.

@KyleAMathews OK, I'll see what I can do!

Functions need some glue code to be supported on different hosting platforms. E.g. Netlify recently added support https://www.netlify.com/blog/2021/06/03/how-to-enable-gatsby-functions-on-netlify/

Functions are compiled to .cache/functions so for Azure, you'd need to deploy those to Azure functions & setup routing.

Thank you Kyle, sorry I have no idea on this, how to run this (.cache/functions likely is some static output) without a plugin like you mentioned above? Azure has a static web app template, which supports the Azure function by default. But I like the api function which gatsby provides directly.

It will be great if you can take a look on this. Thanks

https://docs.microsoft.com/en-us/azure/static-web-apps/add-api?tabs=vanilla-javascript

It's going to take someone with some familiarity with Azure to solve this. Could you reach out to Azure directly?